sharding

sharding-proxy 的相关理论&使用文档参考官网（https://shardingsphere.apache.org/document/legacy/4.x/document/cn/manual/sharding-proxy/）

sharding-scaling 的相关理论&使用文档参考官网（https://shardingsphere.apache.org/document/legacy/4.x/document/cn/manual/sharding-scaling/）

sharding-proxy可以类比于mycat，作为实际数据源的代理，部署为服务，向客户端提供透明的数据库访问。可以结合sharding-scaling来发起数据迁移任务。

sharding-proxy

参考官网下载解压，我使用4.1.0

wget https://linux-soft-ware.oss-cn-shenzhen.aliyuncs.com/sharding-proxy-4.1.0.tar.gz

要确认的是

需要先确认数据库MySQL 需要开启binlog，binlog format为Row模式，且迁移时所使用用户需要赋予Replication相关权限(REPLICATION SLAVE, REPLICATION CLIENT)。

在mysql的my.cnf文件中配置

log-bin=mysql-bin

binlog_format=ROW

还需要注意的是，因为是采用主从同步binlog形式来实现增量数据的同步，所以还需要配置mysql服务的server-id（1到2^32–1之间的一个正整数值）

在sharding-proxy服务的conf文件夹下

server.yaml是代理服务的配置文件，通过配置authentication属性，可以设定代理服务的访问账号/密码，以及对应账号的数据库访问权限

eg:

  这个配置表示配置了两个账号root和sharding，root没有设置数据库权限限制，代表能访问所有库，而sharding账号，则只能访问order库。至于这里的库Schemas，就代表的是proxy对外提供的逻辑库，并不是实际代理的物理库的信息。

config-开头的配置文件，就是对应的规则下的逻辑库和是实际数据源以及规则的配置文件了，注意的是，一个配置文件，配置一个逻辑库。

eg: config-shading2.yaml文件

schemaName: 逻辑库的名称，用于提供给外部客户端访问的库

dataSources: 该逻辑库实际上对应的数据源配置

shardingRule: 分片规则

    tables：表信息

        mysharding：逻辑表名

            actualDataNodes：实际数据节点的配置，图中用行表达式来来配置，映射本逻辑表名和实际表的关系

            databaseStrategy: 分库配置

                line: 采用行表达式

                    shardingColumn： 分库字段

                    algorithmExpression：按照分库字段，数据映射到的实际库的规则

            tableStrategy: 分表配置

                line: 采用行表达式

                    shardingColumn： 分表字段

                    algorithmExpression：按照分表字段，数据映射到的实际表的规则

            keyGennerator: 分布式主键配置

                type: 雪花算法

                column：主键列

以上便是分库分表的配置，代表着，数据将会按照对应规则被分散到实际的数据节点中去。这里只是数据的去向

启动sharding-proxy服务之前，需要注意的是，dataSources的库表，一定要先创建好。

启动后，使用mysql客户端访问，可以看到

逻辑库已经存在，且逻辑表也有，只是目前还没有数据。

sharding-scaling

参考官网，下载解压后直接启动即可。

wget https://linux-soft-ware.oss-cn-shenzhen.aliyuncs.com/sharding-scaling-4.1.0.tar.gz

sharding-scaling作为迁移任务的发起端，对外提供了http接口

这里直接调用迁移任务的接口：

curl -X POST --url http://127.0.0.1:8888/shardingscaling/job/start \ --header 'content-type: application/json' \ --data '{    "ruleConfiguration": {       "sourceDatasource": "ds_0: !!org.apache.shardingsphere.orchestration.core.configuration.YamlDataSourceConfiguration\n  dataSourceClassName: com.zaxxer.hikari.HikariDataSource\n  properties:\n    jdbcUrl: jdbc:mysql://127.0.0.1:3306/h_db?serverTimezone=UTC&useSSL=false&zeroDateTimeBehavior=convertToNull&characterEncoding=UTF-8\n    driverClassName: com.mysql.jdbc.Driver\n    username: root\n    password: 123456\n    connectionTimeout: 30000\n    idleTimeout: 60000\n    maxLifetime: 180000\n    maxPoolSize: 2\n    minPoolSize: 1\n    maintenanceIntervalMilliseconds: 30000\n    readOnly: false\n",       "sourceRule": "tables:\n my_sharding:\n    actualDataNodes: ds_0.t_order\n    keyGenerator:\n      column: order_id\n      type: SNOWFLAKE",       "destinationDataSources": {          "name": "dt_1",          "password": "123456",          "url": "jdbc:mysql://127.0.0.1:8080/my_sharding?serverTimezone=UTC&useSSL=false&characterEncoding=UTF-8",          "username": "root"       }    },    "jobConfiguration": {       "concurrency": 1    } }'

这样看可能不清晰，格式化一下请求的body：

sourceDatasource：配置迁移发起数据库 别名和参数

sourceRule：配置迁移发起库的逻辑映射关系：

    tables：逻辑表和逻辑表对应的需要被迁移的表数据节点，以及主键列和迁移的主键生成算法等配置

destinationDataSources：配置任务要迁移到的数据源信息，这里就是指代理服务sharding-proxy

发送请求后就开始了迁移数据。

在任务执行期间，原来的数据库对那个表的增删改查，也会被同步。

这里要注意：发送请求后，返回{"success":true,"errorCode":0,"errorMsg":null,"model":null}只代表请求发送成功，并不代表迁移任务成功，应当调用查询接口查看

curl -X GET \ http://localhost:8888/shardingscaling/job/progress/{jobId}

同时可以通过连接代理数据库来查看或者统计迁移数据的情况，完成后可以stop迁移任务

这里要注意：停止迁移任务后，原来库表的binlog就不会被同步了，所以最好是在分库分表的业务服务上线替换完成后，再进行停止操作。

至此，迁移任务完成。

基于sharding-jdbc分库分表整合seata实现分布式事务：https://blog.csdn.net/HTslide/article/details/108337372